WASD x86-64 on OpenVMS V9.0-D EAK after less than 8 hours porting effort...

Text from original email...

When we left our intrepid adventures Thursday, the journey had progressed a
mere few steps before grinding to a halt after initialisation.

> %HTTPD-I-BEGIN, 17-SEP-2020 14:07:51, WASD:7080 accepting requests

The issue was found with perhaps three hours further investment the following
day.

Early in the start-up a gethostname() (standard C library networking call)
was returning with user-mode ASTs disabled.  Now, you don't need to know too
much about WASD to understand that disabled AST delivery is an absolute
neurotoxin.  An OS/network-stack/runtime bug.  Reported to VSI (though likely
not for the first time).  Workaround; $SETAST(1) immediately following the
call.

Woosh!  Responsiveness on port 80.

That addressed, the next step for a modern Web, was to secure network
communications.  The OpenVMS V9.0-D VM came with VSI SSL111 installed.  So
far the executable image had been cross-compiled and cross-linked on the
Itanium system.  To build against the SSL111 shareable images the object code
needed to be brought across to the x86 and linked there.  It then reported...

%HTTPD-I-SOFTWAREID, HTTPd-WASD/11.5.1 OpenVMS/X86 SSL
WASD VMS Web Services, Copyright (C) 1996-2020 Mark G.Daniel.
8< snip 8<
%HTTPD-I-SYSTEM, VBOX VBOXFACP VMS V9.0-D
8< snip 8<
K:1 E:2 S:4 U:8 NET:322  !<- debug code before gethostname() user-mode ASTs active
K:1 E:2 S:4 U:0 NET:325  !<- after; user mode ASTs no longer active
8< snip 8<
%HTTPD-I-SSL, OpenSSL 1.1.1g  21 Apr 2020 (0x1010107F)
-SSL-I-PROTOCOL, TLSv1,TLSv1.1,TLSv1.2,TLSv1.3
-SSL-I-OPTIONS, 0x80410854
-SSL-I-SNI, Server Name Indication enabled
-SSL-W-DH, no ephemeral DH param
%HTTPD-I-HTTP2, enabled
8< snip 8<
%HTTPD-I-SERVICE, http://x86v1.vsm.com.au:7080
%HTTPD-I-SERVICE, https://x86v1.vsm.com.au:7443
%HTTPD-I-SSL, x86v1.vsm.com.au:7443
Generate x86v1.vsm.com.au 2048 bit private key:
................++++++++++++
.......++++++++++++++
%HTTPD-I-DEMO, demonstration mode
8< snip 8<
%HTTPD-I-BEGIN, 18-SEP-2020 15:48:59, WASD:7080 accepting requests

A page containing images of the running server is available at

  https://wasd.vsm.com.au/other/WASD%20x86-64%2019-SEP-2020.html

Total time invested (excluding troubleshooting the gethostname() issue);
something less than 8 hours.

Total code changes;

$ search *.c "#ifdef __x86

******************************
WASD_ROOT:[src.HTTPDX]httpd.c;6

#ifdef __x86_64
#ifdef __x86_64
#ifdef __x86_64

******************************
WASD_ROOT:[src.HTTPDX]net.c;17

#ifdef __x86_64

******************************
WASD_ROOT:[src.HTTPDX]sysplus.c;3

#ifdef __x86_64

******************************
WASD_ROOT:[src.HTTPDX]tcpip.c;7

#ifdef __x86_64
#ifdef __x86_64

******************************
WASD_ROOT:[src.HTTPDX]version.c;3

#ifdef __x86_64

A couple of these disable image analysis for reporting purposes; it seems
x86-64 ELF details are different to IA64.  The SYSPLUS.C a similar
disablement for a system call reason.  A couple to report X86 instead of AXP,
IA64 or VAX :-)

Seems a bit too easy.  Of course VMS is VMS is VMS and now VMS.  Mostly.

This is a real-life, almost real-time, porting report on a EAK.  Most
reassuring.  Porting application code should be (relatively) straightforward.
Though I'm pleased WASD doesn't do any kernel fiddles :-|

Trust this is of some interest and use, Mark.